Integrating a Multi-Vendor ESL-to-Silicon Design Flow Using SPIRIT

Peter Grun, Chulho Shin – ARM, USA
Chris Baxter, Christopher Lennard – ARM Ltd, UK
Mark Noll – Synopsys, USA
Gabor Madl - University of California, Irvine, USA

Abstract:

System design flows are traditionally multi-vendor.  The adoption of electronic system-level (ESL) design and highly configurable IP is increasing the dis-aggregation of the supply-chain.  This demands a new kind of information exchange between tools and IP: SoC design configuration meta-data.  Design-flow integration is helped by utilizing meta-data exchange in the design-language neutral SPIRIT XML format.  In this paper, we will show how this standard is helping to close the gulf between ESL design exploration environments and the SoC implementation flows.  We have proven the use of system configuration and integration data exchange on production IP and tools.  We show a SPIRIT-enabled flow from the ARM RealView SoC Designer SystemC tool to coreAssembler, the Synopsys SoC assembly, implementation, and verification environment,  using an ARM1176JZ-STM processor subsystem design example

INTRODUCTION

Customer demand has made support for integrated multi-vendor design flows a necessity for EDA and design IP providers.  System designs and configurable IP must be exchanged rapidly and consistently between the different stages of the design process, the teams that manage those stages, and the specific tools that support them [1][2].  

An example of the issues faced by systems-design houses is given in Figure 1.  This shows a possible multi-vendor and design-language co-ordination of tools and IP in a typical SoC design flow.  It shows the types of design views that must be kept consistent.  It is clear that exchange of design configuration between individual tools cannot be on a case-by-case basis.  Maintaining the consistency of SoC designs today requires a single, language-and-vendor neutral way to express IP and the configuration of a SoC design as it progresses through the refinement process [3].



Figure 1:  Configuration data exchange needed in example multi-vendor flow

In this paper, we introduce the reader to the SPIRIT standard [4] and its usage.  The SPIRIT standard provides an XML schema [5][6] and set of semantic interpretation rules.  A design component can be described with SPIRIT meta-data enabling it to be automatically imported, assembled, and configured consistently through the various stages of a SPIRIT-compatible multi-vendor flow.  The SPIRIT standard also defines the notion of a generator, which is a stand-alone process which can run within a SPIRIT-compatible design environment.  Generators enable the integration of point-tools for manipulation of SPIRIT components within a design environment.  

We provide evidence of production use of the standard on a configurable AXI system-design using the ARM 1176JZ-S processor and tools from at least two vendors currently supporting SPIRIT.

A SUMMARY OF THE SPIRIT STANDARD

The development of the SPIRIT standard has been split into two phases, the first (SPIRIT 1.x) is to address RTL design and verification flow integration, and the second (SPIRIT 2.x) is to address electronic system-level design. The first versions of the SPIRIT standard have already been proven against production RTL design exchange.
    
 

Figure 2:  SPIRIT usage in a SoC Design Environment

The typical usage model for SPIRIT within a design-environment is shown in Figure 2.  The user of such a design environment will be able to gather SPIRIT component descriptions (files) together into a library, along with SPIRIT-compatible definitions for any bus interfaces referenced within the components. The key contents of a SPIRIT 1.x component definition include: top-level I/O, bus interfaces, definition of memory map, the various views of the IP, including the files required to ‘see’ a particular view, and implementation constraints which must be met in order for the IP to properly function within the subsystem.  SPIRIT bus definitions define a standard connection protocol and the bus interfaces within a SPIRIT component description are essentially an instantiation of the bus definition. For example, there is a standard bus definition for an APB slave interface. A simple slave such as a watch-dog timer might then contain a bus interface, instantiating the APB slave bus definition. This provides all of the information necessary to attach the peripheral to the APB bus fabric.

A design environment (integrated tool flow) can instantiate and connect SPIRIT components to form a design, which is itself represented as a SPIRIT design file. A SPIRIT design file describes which components are instantiated, how their bus interfaces are connected, component configuration details, and any ad-hoc, or non-interface based connections between components. It is expected that systems integrators will want to augment the functionality of their design-environment with point-tool functionality.  These are tools called to implement specific design, or design verification, tasks. Therefore, SPIRIT defines the concept of generators, which can be plugged into any SPIRIT compatible design environment to provide custom features. In the 1.1 schema, generators communicate with the design environment using a loose generator interface (LGI). This is a file based API which provides access to the component and design files comprising the current design, and which supports updates (primarily component replacement and connection changes) through an LGI changes file.  This is processed by the design environment when the generator has finished running. The SPIRIT 1.2 schema will provide a much finer grained interface, known as the tight generator interface (TGI). This language neutral interface utilizes SOAP [7] for communication between generator and design environment. Generators can use the TGI to get any information represented by the SPIRIT schema files, and can set the value of any element which has been defined to be user resolvable, as indicated by the existence of the ‘spirit:resolve’ attribute set to the value “user”. SPIRIT generators can be invoked individually or they can be linked together using a SPIRIT generator chain.  This is another SPIRIT file type, used to describe sequences of generators which should be run as a unit.

There are two additional types of SPIRIT files that can be utilized in a SPIRIT design environment. The first is a platform meta-data file (PMD) which describes transformations that should be made to a component when it is instantiated in a design environment and when certain conditions are met. For example, when instantiating an APB slave, a PMD file might be used to specify certain configuration values if another dependent APB slave is already instantiated in the subsystem. The second additional file type is new to the SPIRIT 1.2 schema. The design configuration file is used to store information that is not component or design specific. This includes the currently selected view of each component, and configuration values for generator chains and PMD files.

Version 2.0 of the SPIRIT standard addresses the Electronic System Level (ESL) and transactional verification IP. The SPIRIT v2.0 standard will enhance interchange of models described at different level of abstraction by providing a way for IP providers to describe the interfaces used by their models, and identifying transactors that are needed to integrate those models into different simulation environments. SPIRIT v2.0 supports the concept of abstraction levels through component ‘views’, and bus interface ‘abstractions’.  Given this information, multi-level system simulations can be automatically built from a topological system description and configuration in SPIRIT.

In Figure 3 we show a simple example of a multi-abstraction design, where a SPIRIT v2.0 design can be configured using the SPIRIT configuration files to target different levels of abstractions.  The component “views” are used to represent the different abstraction levels of the component.  The connectivity of the system must be kept consistent as different IP views are switched in and out.  Maintaining that connectivity will often imply the insertion (or removal) of transactors that translate interface activity between abstraction levels.  This implication can be deduced from the SPIRIT connectivity requirements.

 

Figure 3:  Hierarchy of views and busInterfaces in SPIRIT 2.0

Beyond simple transactor insertion, different levels of abstraction of a component usually exhibit differences in the interfaces supported. For example, the RTL interface in general will be more refined, containing more details then the TLM interface.  This requires that consistent concepts of connectivity be transported between system views, while other detail can be added / removed specific to the system view.   This is supported in SPIRIT v2.0 by a set of interface and abstraction level constructs including the “bus interface”, “bus abstraction”, “abstraction definition” and “bus definition” constructs.   In  Figure 4 we illustrate this in more detail with an example component (a microprocessor) that contains 2 views: the TLM view and the RTL view.   In the ESL view of the system the microprocessor is connected to a transaction-level system-bus.  At the RT level, there is connectivity to both system and interrupt buses.  Through the separation of abstraction definitions and bus definitions, SPIRIT enables the system interconnect constraints to be transported between these different views of the system.

A bus IP is defined by a “bus definition”, describing the list of signals for wire to wire connections. The “abstraction definitions” represent the abstraction levels of that bus IP, and reference the “bus definition” they belong to. Each component may contain one or more bus interfaces. Each such interface allows connecting the component to a bus. The bus interfaces will contain “bus abstractions” that reference the “abstraction definitions” they correspond to. In the example from Figure 4, the System and Interrupts bus definitions are referenced by their respective RTL and TLM abstraction definitions. Both the RTL and TLM views of the component reference the Memory bus interface, while the RTL view references the Interrupts bus interface.

 

Figure 4:  Support for multiple levels of abstraction in SPIRIT 2.0

By supporting descriptions at different levels of abstractions to have different interface footprints, structural consistency between different simulation levels is formalized.  This allows users to move rapidly between views of the design trading off different goals such as simulation speed and accuracy seamlessly.  The complete design flow is driven from a unique topological SPIRIT design file.

MAPPING A SystemC DESIGN TO SPIRIT

All SoC design tools maintain an internal database to act as a repository for the system model connectivity, register and bus-interface configuration, and system memory maps. For a SPIRIT-compatible design environment, this database is related to a SPIRIT description of the IP and system. An example is shown in Figure 5, where the internal database is identified as (.mxp). In general, such a tool will have a wizard for manual edits to the SPIRIT-specific view of the design, as well as supporting automatic import for existing SPIRIT files. In this way, regardless of an internal proprietary data-base format, the import of a design IP import will capture and create the multi-vendor  SPIRIT description for an IP.  

Changing connections, duplicating, removing or configuring components in a system design will automatically update the design tool’s internal data-base.  As part of the SPIRIT standard, it is mandatory that any SPIRIT-compatible design-environment also reflect these changes into the SPIRIT description of the full design.  Hence, once an optimal design is determined using fast models at the ESL level, the language-neutral description of the system interconnect and configuration can be exported immediately to an RTL tool.

Mapping of a SPIRIT design to the SystemC interface constructs is enabled through simple equivalence relations between the SPIRIT and internal tool data structures. In the example of Figure 5, the ESL design environment works with two different kinds of internal configuration files. One is a library configuration file (.conf) and the other is a design file (.mxp). A library configuration file contains IP library-specific information such as library types and paths. A design configuration file contains information such as IP instance names, connectivity and instance-specific parameters.

 
Figure 5:  SPIRIT usage in an ESL design tool

To enable complete import and export between design environments, SPIRIT requires the addition of explicit data-handling detail which otherwise may be implicit in a single tool.  The library and design configuration files need to be annotated to express design IP properties (SPIRIT library module name and path), ports (SPIRIT port name, type and corresponding SPIRIT bus interface VLNV), and a TLM-to-SPIRIT port mapping table reusable across designs.  

For TLM support, the internal design configuration file (.mxp) must be annotated to support SPIRIT channel information.  Channels are IP connection elements with specific interfacing rules that enable netlisting between masters and slaves for non-symmetric protocols (e.g., AHB master and slave interfaces are non-symmetric). Channels are handled as pseudo-elements in the ESL design tool  as they are not necessary for ESL connections.  This is due to the fact that there is no concept of symmetry in signal interfaces at the TLM level.  

USING SPIRIT TO ENTER THE HARDWARE IMPLEMENTATION FLOW

To move from an ESL tool to a hardware implementation tool, the SoC design must cross a design environment and design language boundary.  In this case, we are examining the flow from a SystemC ESL design tool exporting a SPIRIT representation (components and designs) of the SoC design to a design environment supporting a path through to implementation.  To enter this hardware implementation process, it is most important that the script generation process is directly enabled.  Automation of this process allows the user of the design environment to leverage the expertise of the script generation authors without requiring them to become an expert in the implementation tools themselves. A script generator takes into account the specific aspects of the implementation flow being used, including specific tools and tool versions, the specific target technology (including details about cells available in the library), the subsystem design constraints, and information about how each IP block is ‘intended’ to be implemented.   We describe the latter two aspects of this flow.

Subsystem design constraints include input/output timing requirements, DRC requirements, external drive/load characteristics, clock definitions, and timing exceptions such as false and multi-cycle paths. This type of synthesis information is well standardized in the industry, and common to multiple flows.  As such, this information can be provided directly in the SPIRIT component file. A set of example constraints specified using the SPIRIT constraint schema is shown in Figure 6 below for a typical input signal.

 

Figure 6:  Example design constraints for an input signal

Constraints are specified in a technology independent manner whenever possible. In the constraint example, both the input delay constraint and the drive constraint are specified without reference to a particular implementation technology. This greatly enhances the portability of the constraints as the IP can be targeted to different technologies without any updates to the SPIRIT meta-data.

Synthesis ‘intent’ is the final critical input to the script generation process.  This is (mostly) tool independent information about how an IP block is intended to be implemented. For example, an IP developer might indicate that a particular block contains many arithmetic components.  The script generator can then create a script for that IP block which focuses more on arithmetic optimization than it would in the default case.  This ‘intent’ is what drives the script generator when creating a script to compile a specific IP block. There are a number of different pieces of information which can be specified for synthesis intent, including: optimization focus, design characteristics, hierarchy preservation, blocks, to compile, customizations, DFT intent, and physical intent. While a common concept, the expression of intent is often vendor specific.  SPIRIT enables the capture of the specific parts of this implementation flow through use of vendor-supplied extensions.  

The synthesis script generator must be able to generate scripts for the targeted implementation tools which provide excellent quality-of-results, without requiring any manual modifications.  Otherwise the value of the automated process is not high enough to justify the loss of control over the implementation flow. Manual modifications should not be required, but controlled customization must be allowed to account for special implementation requirements which inevitably occur when implementing a large subsystem. A common customization example is the need to prevent the use of specific cells from the target technology library.

There are two primary steps required to generate the implementation scripts. First, conflicts between implementation constraints must be resolved. An assembled subsystem may have a common input signal connected to an IP block which has a ‘40% of the cycle time’ input delay constraint, and to an IP block which has a ‘60% of the cycle time’ input delay constraint. The most practical solution is to keep the more pessimistic constraint (tighter delay constraint, larger load constraint, weaker drive constraint, etc.). Second, the script generator must leverage its knowledge of how to drive the selected implementation tools, and information gathered from analysis of the target technology libraries, to transform the synthesis intent into the actual generated scripts used to drive the implementation tools. The process described above is highlighted in Figure 7.
 

Figure 7:  SPIRIT enabled HW implementation flow  

A SPIRIT DESIGN FLOW IN PRACTICE

We have developed an integrated system-design flow using a SystemC representation for system validation and performance analysis, and an RTL representation used as the entry point into the implementation flow.  The ARM SystemC design environment RealView SoC Designer with MaxSim® technology [8], and the Synopsys coreAssembler [9] tools have been used to validate this integration through SPIRIT meta-data exchange.  The design validation was performed on an ARM1176JZ-S processor core subsystem.

The example ARM1176JZ-S processor core subsystem supports the basic components required to enable embedded software to be executed by the processor core (i.e. RAM, ROM, a timer and interrupt controller).  This is connected using AMBA AXI bus fabric infra-structure components.  All of these components have RTL views, and corresponding SystemC models within the ARM RealView SoC Designer ESL tool, enabling fast cycle-based simulation.  The transaction level interface used is the ARM RealView ESL simulation API, a cycle-based transactional interface.   The experiments were performed using SPIRIT v1.1.
 
ARM initially captured SPIRIT meta-data for the core and subsystem components, including:

• The RTL I/O signals.
• Any design files are used to describe the functionality of the component e.g. Verilog RTL source files. Multiple sets of design files can be defined to support different views of the components implementation, e.g. Verilog and VHDL RTL views.
• The interfaces supported by the component at an abstract level (e.g. a AXI slave port) and the I/O signals used to implement the interface.
• For simple peripherals with standard interfaces, it takes less than half a day to capture and validate SPIRIT descriptions.  For cores with multiple complex bus interfaces (e.g., co-processor, interrupt bus, etc.), the engineering time to capture a SPIRIT description depends on the degree of re-use of validated bus definitions.  After completion, the SPIRIT component definitions were imported into SoC Designer and the coreAssembler tools.

In the SoC Designer tool, a SPIRIT SoC design definition is relatively straight forward to create as it is only required to define the components instantiated in the design, the parameter values associated with the instantiate components and the interconnect between the interfaces provided by the components.  As there is a direct alignment between the SPIRIT and SystemC component interface definitions, the SystemC representation of the system is a direct mapping of the design definition held within the SPIRIT design definition.  

As the present SPIRIT v1.1 definition of the SPIRIT schema only provides explicit support for RTL interfaces, the definition of component interfaces at the SystemC level is performed by overloading the SPIRIT interface definitions within the component meta-data. This implies that the names defined for the SPIRIT interface definitions and the SystemC interfaces must be identical. This support of direct port-to-pin mapping enables the SoC netlist to be directly translated from SystemC model interconnect to RTL component connectivity.

After completion of the system level simulation, the subsystem was exported in the SPIRIT format and imported into the Synopsys coreAssembler tool to begin the path to implementation. The SPIRIT export/import process enables an automatic transfer of the components and their connectivity from the system level design environment into coreAssembler. In this particular case, the front-end portion of the coreAssembler flow (IP assembly) has been completed in RealView SoC Designer so the subsystem designer can move directly to the implementation flow. The first step in this flow is to choose a target technology library. The library is analyzed in coreAssembler in order to choose the optimal cell set for synthesis and to allow the tool to convert technology independent constraints into constraints specific to the chosen technology. The next step in the flow is to override component level constraints as appropriate for the context in which the subsystem will be used. The subsystem designer then chooses an implementation strategy targeting one or more of the following tools: Design Compiler, Physical Compiler, DFT Compiler, DC-FPGA Compiler, TetraMax. Synthesis scripts and a top-level makefile are then generated automatically, taking the tool version, target technology, and optimization constraints into account. The makefile enables both parallel implementation of components in the subsystem, and reproducibility outside of the coreAssembler environment. After the synthesis process completes, generated reports are automatically converted to HTML and summarized to enable efficient review of the results and to help pinpoint problems if constraint violations exist. The end result is an automated process which provides excellent quality-of-results [10] without manual intervention across all of the key Synopsys implementation tools.

CONCLUSIONS 

The SPIRIT standard is already being proven to resolve some difficult integration issues with multi-vendor / multi-language flows.  We have shown flow integration from SystemC to Verilog, across two tools from two vendors.  This was shown on production tools featuring SPIRIT support.

There is an excellent future for the adoption of the SPIRIT standard.  It is immediately useful for RTL and structural SystemC IP exchange, and over the next year we will see meta-data exchange across multiple levels of design abstraction.  Given the increasing complex set of design views that must be kept consistent from architecture inception to final silicon, the role of SPIRIT will become increasingly critical for efficient design-chain integration.

REFERENCES 

[1] FPGA Journal: “Samsung's ViP Design Methodology Reduces SoC Design Time Up to 40 Percent” http://www.fpgajournal.com, September 2004

[2] Alberto Sangiovanni-Vincentelli, Grant Martin, “A Vision for Embedded Systems: Platform-Based Design and Software Methodology”.  IEEE Design and Test of Computers, Volume 18, Number 6, November-December, 2001, pp. 23-33.

[3] Christopher K. Lennard, Eric Granata,  “The Meta-Methods:  Managing design risk during IP selection and integration”. European IP 99 Conference, November 1999

[4] SPIRIT Consortium, “SPIRIT 1.1 Specification”, www.spiritconsortium.org, June 2005

[5] World Wide Web Consortium, “Extensible Markup Language (XML) 1.0” Third Edition, 2004

[6] World Wide Web Consortium, “XML Schema Part 1: Structures”,  Second Edition; “XML Schema Part 2: Datatypes”  Second Edition, 2004

[7] SOAP Specifications:  www.w3.org/TR/soap

[8] ARM RealView ESL Tools:  www.arm.com/products/DevTools

[9] Synopsys IP Reuse Tools: www.synopsys.com/products/designware/ipreuse_tools.html

[10] Gerard Humeau, Xavier Robert, Jehan-Philippe Barbiero, Julien Guillemain, Gauthier Barret, “Enabling the Delivery of  Super10 Nexus On-Chip-Emulator as Soft IP”, SNUG Europe 2003