Automated Implementation Flows based on IP-level constraints and synthesis intent in XML

Denis Bussaglia, Synopsys Professional Services
Marino Strik, Philips Semiconductors
Mark Noll, Synopsys Solutions Group
Geoff Mole, Philips Semiconductors
Ralf Gaisbauer, Philips Semiconductors
Hans Peter van Lohuizen, Philips Semiconductors

Abstract

This paper describes an innovative methodology that makes use of XML-based IP descriptions, including constraints information, to produce automatically synthesis, STA and formal verification tool scripts for sub-systems. The XML information can be considered to be a ‘machine readable, electronic data book’.

The work is related to the standards being set in the Spirit consortium. Implementations of tools interpreting the XML information have been built in order to prove the concepts.

This paper describes two design environments; both supporting automated implementation flows.

1 Introduction

For Semiconductor Companies like Philips, it has become critical to be able to produce fast derivative designs after an initial release, in order to react promptly to market demand. This has led to an everincreasing use of IP. However, to achieve significant reductions in turnaround time over existing methodologies, the assembly, configuration, verification and implementation of a design must all be highly automated.

With a traditional IP packaging and IP integration methodology, it takes time and effort for a SoC integrator to manually create or adapt scripts for front-end implementation. As a consequence the productivity gain of employing an IP-Reuse methodology for SoC design decreases dramatically. To improve productivity these task need to be automated. The design trajectory becomes less errorprone, less dependent of the actual designer and reproducible.

In the following sections, we describe the specific requirements and goals we want to achieve in automating the front-end implementation. Then, we explain how XML-based IP metadata can enable this vision and how it is supported by a standard provided by the SPIRIT consortium. Finally, we present two automated design environments that demonstrate real applications and evidence that this methodology can be applied to real-world designs.

2 Requirements

Platform based design requires the availability of an IP portfolio. This IP portfolio must contain HW and SW IP which is reusable within an application domain. Different system designs can be built with different compositions of the available IP. The view of the IP needs to be ‘parameterized’ as the IP needs to be usable in a different context. For example the synthesis/timing constraints need to scale with the clock frequency applied. Timing exceptions (false paths, multicycle paths) inside the block must be applied at the correct level of hierarchy also after integrating the IP in a system.

Having a solution to capture constrains and timing exceptions with the property of being adaptive to the context at which the IP is applied, enables automated creation of scripts for Synthesis, DFT, STA and formal verification.

3 Technology background / related work

As described in [1], the use model defined by SPIRIT (Structure for Packaging, Integrating and Re-using IP within Tool flows) is based on the Design Environment (DE), as shown in Fig. 1.

Figure 1. SPIRIT Design Environment (DE)

Spirit provides an XML schema. This meta-data schema enables a way to describe IP through a common format, compatible with automated integration techniques and enabling integrators to use IP from multiple sources with SPIRIT-compliant tools. The XML meta-data for a component describes the properties of the component IP and the package in which it is delivered. The XML meta-data can be seen as a machine readable electronic data book.

The SPIRIT v1.1 standards release is intended to comprehensively address Register Transfer Level (RTL) design, including packaging configuration and SoC integration.

In order to support automated IP integration, the SPIRIT consortium enhanced the v1.0 XML schema with constraints on signals, components and busses. The constraints are based on a donation from Synopsys and are tool-independent.

The concept of defining a reusable set of constraints for an IP already existed prior to SPIRIT. Synopsys coreBuilder has long had the ability to capture synthesis intent when packaging an IP. For instance, it supports timing constraints based on percentages of clock period, which makes the reuse of constraints straightforward for different integration projects.

This feature is key to a predictable and successful integration of different IPs in a SoC. Let’s take the example of masters and slave IPs integrated on a bus structure. Functional verification of the bus protocol is necessary but obviously not sufficient. An organization can now enforce timing budget checks against a specific bus timing budget. This increases the confidence that the automated integration will work.

This kind of technology is now supported by SPIRIT release v1.1.

In this use model, external generators can also be used to enhance the capabilities of a design tool during the build process.

4 Automated implementation flows

We present two design environments that provide automated sub-system implementation. Both support XML IP meta-data (with constraints) as input.

Nx-Builder

Flow

Nx-Builder allows a user to compose a sub-system using an XML view of IP which is available in a repository. All information required to perform user interaction and context analysis is present in this XML catalog view. When a user is ready with the input side, then a build of the system starts the process where Nx-Builder derives from user input and context analysis the configuration parameter values for each IP. Next IP is configured and downloaded from the IP repository using these configuration parameters. The downloaded IP provides a new more detailed XML description of the IP and it replaces the initial ‘catalog view’ XML. The detailed XML has all information required for the generation of a RTL top-level. Furthermore it provides all information for an automated simulation and implementation flow which writes out scripts and control data for other EDA tools.

The Nx-Builder tooling for sub-system integration and verification was extended by a collaborative team from Philips Semiconductors and Synopsys Professional Services to enable seamless front-end implementation.

A java generator was developed for automated creation of scripting for Synopsys tooling (i.e. Design Compiler, PrimeTime and Formality) based on IP and sub-system XML meta-data input.

The XML electronic data book of Nx-Builder supported IP blocks has been extended. This includes industry standard and proprietary programmable processors.

The added XML information provides timing constraints and file sets to be used for logic synthesis/formal equivalence checking. Implementation-specific XML information makes use of the SPIRIT schema for constraints as well as a few proprietary additions: timing modes and synthesis steps.

Implementation-specific XML inputs

The SPIRIT constraint schema is extended with the concept of timing modes and implementation steps. The current solution defines only functional and scan test modes, but could be extended to support a fullfledged solution. Synthesis makes use of functional constraints only, while STA can be run for the two modes.

The following shows a default clock definition for a flash controller IP. Note the functional and scan test modes:

The nx: XML namespaces which you see used in the examples enabled prototyping functionality before the final Spirit 1.1 standard was released. Now that the Spirit standard is available a merge of constructs is planned.

Now, the timing constraints (SPIRIT-compliant) on the IP ports are, by construction, relative to the mode selected for the constraining clock. Below, the maximum input delay is relative to the mode selected for the clock ‘ahb_clk’ above.

Implementation steps help define the handling of global nets for synthesis and STA. Here, the reset signal is defined as an ideal network, except for postlayout STA.

Timing exceptions like false paths, multi-cycle path and timed paths can also be defined relative to a mode. Here, all paths to the dcm pin are false paths in all functional modes. Indeed, the base ‘functional’ mode could be specialized into several modes all starting with the ‘func’ prefix.

A link to the IP db file and synthesis run script is required to create a bottom-up compilation:

Some IP include hard macros, so a link to the lib files was added to the XML.

Note that SPIRIT file sets could have been used to support the db, run script and link libraries.

Generator

The generator plugs into Nx-Builder flow and makes use of its API to access component and design XML information. It creates a makefile for various synthesis strategies as well as synthesis/STA/formal verification TCL scripts. The principle is to reuse Philips template scripts and fill in specific sections according to the sub-system. There are dedicated toplevel scripts for clock definition, IO constraints, timing exceptions and clock timing exceptions. Based on the configured instances in the sub-system, the generator finds and propagates constraints to the top-level. The assumption is that every pin at the top connects directly to a pin on an IP. Alternatively, we could have glue logic at the top, but it should then be accounted for as timing budget into IP.

Output scripts

The generator makes use of a STEP variable in output scripts. STEP can be either SYNTHESIS, IDEAL (pre-layout netlist STA) or propagated (post-layout netlist STA).

Clock definitions are all written to a dedicated TCL script and depend upon the selected STEP and MODE. Below, only the functional mode for the clock connected to the flash controller is shown. Many more clocks exist at top-level. Similar definitions are present for scan test mode. Signal names are prefixed with instance name (efc in this case).

Top-level IO constraints script contains all constraints for top-level pins, ordered per component instance and per pin. Here is an example for the acu signal propagated to the top.

Below is an extract of the timing exceptions script which shows the section dedicated to the dcm pin.

Reuse

The constraints output format includes a path variable, which enables the use of these constraints at different levels in the design hierarchy. This is very useful when integrating the sub-system at chip-level where the timing exceptions can be reused without modification. From an integrator point of view this is highly appreciated, as timing exception creation requires significant IP implementation knowledge. I/O constraints need modification when used at a higher level of integration the user must select constraints for signals that are exported to the upperlevel of hierarchy as well as potentially changed pin names.

The Nx-Builder synthesis script generator produced 90% of the scripts used for netlist creation of two sub-systems, which had tape-out as part of a SOC (see [6]). Both subsystems (ARM9 and ARM11- based) contain multiple hard macros as well, for which the scripting refers to timing models.

In the context of synthesis and constraints the clock generation unit component is exceptional. We are not aware of an EDA supplier and or an IP provider to market this function as a configurable and reusable system component. It is however one of the key components to make the step from peripheral subsystem towards full chip. The Nx-Builder flow supports the integration of a configurable and generic clock generation unit. This is a particular example where expert design and constraint knowledge is made available to all users of the tooling.

Since end of 2005 XML constraints are part of the standard flow for IP packaging in Philips Semiconductors. Nx-Builder will be compliant with SPIRIT 1.1 and 2.0 in the future.

Systems like Nx-Builder, which automate the bookkeeping of design data, interconnect creation, IP configuration and flow script creation allow for updating chip compositions in matter of hours. Next to the improved productivity for implementing changes, we claim that the risk of not processing the full consequences of a change is dramatically reduced. This is valid for all areas of design. However in the area of synthesis and constraints this is especially valid and valued as an enormous improvement over the manual alternative.

coreAssember

The coreAssembler tool provides an automated flow to assemble, configure and implement subsystems of reusable IP blocks which have been packaged using the Synopsys IP packaging tool (coreBuilder), or which have a SPIRIT component representation.

After a user has assembled and configured their subsystem, he chooses an implementation tool (Design Compiler, Physical Compiler, or FPGA Compiler, and optionally DFT Compiler) and provides the required input information. The coreAssembler implementation flow supports full script generation for Design Compiler, Physical Compiler, FPGA Compiler, DFT Compiler, and Tetramax, enabling a full implementation flow including test logic insertion and test pattern generation. The generated scripts leverage Synopsys expertise in how to best drive the tools to achieve the best quality-of-results. The script generator takes into account the specific version of the implementation tool being used, 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. The latter two inputs to the implementation process will now be described in more detail.

The 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. coreAssembler supports Synopsys coreKits or SPIRIT 1.1 compliant XML for IP, including the new constraints information, based on Synopsys donation to SPIRIT. After a design has been fully configured, coreAssembler automatically propagates all of the component level clock definitions and constraints up to the subsystem level. Conflicting constraints are handled by propagating the more pessimistic constraint upward. After constraints have been propagated, they can be modified by the user to meet their specific needs if required. Constraints specified in a technology independent fashion remain technology independent until synthesis scripts are generated. This means that a delay constraint specified as a percentage of the clock cycle time will always reflect the last specified clock cycle time.

The final critical input to the script generation process is the synthesis ‘intent’. This is 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.

There are a number of different pieces of information which can be specified for synthesis intent, including:

• Optimization focus: timing, area, or both in particular order – generated scripts are significantly different for area focused designs when compared to timing focused designs.
• Optimization directives: is the design mostly arithmetic, heavily pipelined, or complex in terms of sequential elements? Would the design benefit from flattening (levels of logic)?
• Hierarchy preservation – whether boundary optimization is allowed, whether the block must be ungrouped, must not be ungrouped, or can optionally be ungrouped.
• Blocks to compile – controlling top-down vs. bottom-up or hybrid synthesis process.
• Customizations – script fragments provided by the IP developer or subsystem integrator to be inserted into the automatically generated synthesis scripts.
• DFT intent – directives describing DFT insertion requirements.
• Physical information – floorplan or other physical information required for an RTL to placed-gates implementation flow.

As is the case with the design constraints, most of the synthesis intent will be specified as part of the IP packaging process (for IP packaged with coreBuilder) and this information can then be overridden as need by the coreAssembler user. Specification of synthesis intent is not currently supported directly within the SPIRIT component schema, although coreAssembler will soon support this through the use of SPIRIT vendor extensions. coreBuilder supports the packaging of implementation intent for an IP in a technology and tool independent manner.

Using all of the information described above, the synthesis script generation process is able to generate scripts for the targeted implementation tool which provide excellent quality-of-results, typically without requiring any manual modifications. The scripts are run from an automatically generated Makefile which enables reproducibility outside of coreAssembler, and parallelization of the synthesis process. In addition, the scripts create many standard implementation reports, and convert the reports into cross referenced HTML files. This can significantly reduce the time required to analyze synthesis results or to track down issues when your constraints have not been met. The alternative is to review thousands of lines of report data for IP that the subsystem integrator typically knows very little about.

The coreAssembler implementation flow has been used to implement many subsystems at many different customer sites. These subsystems range from simple AHB/APB subsystems to complex proprietary bus based subsystems utilizing internal and third-party IP. The results obtained from this flow typically meet customer requirements without manual intervention and in some cases have resulted in up to 30% area reduction [5].

Automation of the implementation flow as described above for coreAssembler provides the following critical benefits:

• Faster time to market – system integrators do not need to create their own implementation scripts.
• Leverage IP designer know-how – IP design and integration are typically done by different groups at different sites. Including constraints and synthesis intent as part of the IP packaging allows the IP integrator to automatically leverage this information from the IP designer.
• Leverage latest features of implementation tools – generated scripts target the specific version of the tool being used so ‘legacy scripts’ become a thing of the past.

5 Conclusion

In this paper, we describe two automated implementation flows for sub-systems, supporting and making use of the SPIRIT encapsulation of IP. These two flows demonstrated success with real-life projects by enabling the creation and implementation of new and derivative sub-systems in typically a fraction of the time a manual flow would require.

Both flows show that script generation based on expert templates is possible with as major benefit that legacy effects from IP level scripts are reduced. Timing constraints and timing exceptions are propagated and create a starting point far better than IP level scripting or documentation only.

Currently the capabilities are being deployed with a focus on subsystem creation for both ASIC and FPGA flows.

In the future, the implementation flow will be enhanced to move up from sub-system to chip-level.

6 References

[1] SPIRIT User Guide V1.1, www.spiritconsortium.org

[2] Philips Semiconductors Next Generation Architectural IP ReUse Developments for SoC Integration, Geoff Mole, Marino Strik (NL), Matt Muschol, IP/SoC 2004

[3] coreBuilder User Guide

[4] coreAssembler User Guide

[5] Enabling the delivery of Super10 Nexus On-Chip- Emulator as a Soft IP, Gerard Humeau, Xavier Robert, Jehan-Philippe Barbiero, Julien Guillemain, ST Microelectronics; Gauthier Barret, Synopsys Professional Services; SNUG Europe 2003

[6] Philips Semiconductors SJA2510 SoC press release