Platform Based Design using a design meta-database

By Robert de Gruijl, Magnum Semiconductor Inc

Abstract

In this paper we introduce a method for platform-based design and integration of a System on Chip (SoC) using a centralized design meta-database from which all related design data such as EDA tool command scripts, Hardware Description Language (HDL) files, design constraints and user- documentation can be generated. In this meta-data centric approach we aim to keep the required tool chain complexity and the minimum required meta-data for an IP as low as possible. Using this approach, we show a very cost-effective way of leveraging the benefits of platform based design. We show some of the key features of our design flow architecture, and how the flow handles certain typical design problems.

1 Introduction

Platform based design is a widely used methodology in SoC development to manage the ever increasing SoC design complexity and to reduce time to market [2] [3]. Efforts to standardize packaging of IP meta-data to simplify reuse across different SoC development teams and EDA tools have been underway for some time [5]. Also, several platform based EDA tools automating much of the IP-generation and integration are on the market today [4].

Although platform design tools are very powerful and can significantly improve design productivity, the complexity of these tools as well as the required amount of meta-data for each IP to be usable in this tool chain can be costly. In this EDA tool centric approach, the resources to develop and maintain or purchase this EDA tool chain, as well as the required effort of collecting and formatting all the required IP meta-data to use a new or revised IP in this EDA tool chain can outweigh the benefits.

In this paper we present a meta-data centric approach of platform based design, where we focus on creating, for each SoC component, a limited but sufficient amount of sets of meta-data, i.e. IP views, from which actual design data can be generated. We aim for keeping the more complex optimization problems of a design in the hands of the SoC architect, and not hide away the architectural complexity of the SoC behind an EDA tool user interface. This way we can keep the complexity of automated generation and integration of IP low with separate, dedicated scripts or generators. Also, there is a low meta-data threshold for IP to be usable in the platform design flow, so benefits of increased productivity can start early in the meth-odology deployment before all IP views are fully mature.

2 Objectives

We developed our platform based design method using a centralized design meta-database with the intention to meet the following major objectives.

• Reduce risk of design errors by using a single source for design meta-data and use automated generation of design data from this
• Maximize automated generation of design data to increase productivity and reduce time to market
• Keep related tool chain functionality simple, mostly restricted to parsing and formatting of contents
• Minimize the amount of required meta-data for an IP to be usable in the methodology in order to keep overhead down for new or revised IP

3 Flow architecture

Figure 1 below shows the relations between the design meta-database and the various SoC design flow steps. The main role of a SoC integrator will be to create the centralized design meta-database by collecting all IP meta-data, to create SoC specific configurations for each IP and to specify the connectivity between all IP.

Figure 1: Relation between meta-database and SoC design flow steps

From this created meta-database, we can automatically generate actual design data that will serve as input to the multitude of EDA tools in-volved in the SoC design flow. Examples of this generated design data include:

• SDC constraint files for synthesis, place and route, and Static Timing Analysis (STA)
• Command scripts, HDL file lists and library file lists for EDA tools for simulation, emulation, synthesis , etc
• Verilog/VHDL code for top-level, core or subsystem wrappers that instantiate, parameterize and interconnect IP
• Configuration files for configurable IP such as I/O multiplexers, register files and Clock Generation Units (CGU).
• Regression test lists for functional verification
• Command scripts for memory compilers
• User documentation

Figure 2 shows a simplified flow diagram. The SoC meta-data is created by collecting all relevant IP meta-data, and then adding information such as IP configurations, a specification of the SoC hierarchy, IP instantiations and connectivity, register address mappings, information about the target mapping technology and the desired I/O pad configuration.

Some IP configurations will obviously be depending on the number and types of other IP instantiated in the SoC. Examples of this include a Clock Generation Unit, whose configuration depends on the types of clocks required by all IP, and an address decoder for a system interconnect bus, whose configuration depends on the register address mapping of each IP. We make all this IP configuration information available in a centralized SoC design meta-database, which allows us to automatically derive IP configurations from it.

This creating of IP configurations might be a fully automated process, such as in the case of an I/O multiplexer configuration whose number of ports and connectivity is a simple function of the number of chip pins and the number of required functional in and outputs. In other more complex cases the extracted meta-data can be used by a SoC architect to create an optimized IP configuration, for example in the case of a Clock Generation Unit whose configuration is a more complex function of various SoC design parameters.

3.1 Meta database architecture

We use XML to capture design meta-data, and have created several XML schemas defining the database structure. Each SoC component has design meta-data captured by a set of design views, each represented by a separate XML file. This set is accessible through a single XML file listing all the design views for the component, called the XML File Set. Figure 3 shows all design views that can be part of a component’s XML file set.

A special design view is the hierarchy design view, which specifies a set of sub-component instances for this component, as well as their interconnections. Each sub-component has a link to an XML file set describing it, allowing the tool chain to access the full design hierarchy by specifying a single top-level XML file set.

Using XML lets us choose from a multitude of readily available parsing and editing tools. With XML style sheets, we are able to publish accurate SoC design information on the company intranet (for example IP development status for project managers and IP register address mappings for software developers). With DocBook [6] we can automatically generate user-documentation content from design meta-data, such as chip pin descriptions and register specifications.

Figure 2: Simplified design flow diagram

3.2 Generating design data at different hierarchy levels

To be able to split up the SoC design work and run EDA tools at SoC sub-components, we want to be able to generate design data from the same meta-database at any hierarchy level of the SoC. For example, if we want to use a bottom-up synthesis approach as a ‘divide and conquer’ strategy for big designs, we can indicate in the SoC ‘hierarchy’ view in the design meta-database that we want block-level synthesis for a specific IP. The tool chain then generates all required constraint files, synthesis scripts, HDL file lists and library lists for synthesizing this IP separately. Consequently, the generated synthesis-script for the component instantiating this IP will automatically receive a reference to a generated netlist instead of the IP HDL code.

In this example, we would use the same tool chain and the same SoC meta-database to generate design constraints for multiple levels of hierarchy, for example an IP, a core component or a SoC top-level component. The generators in the tool chain automatically export relevant constraints driven from the IP up to the level where constraint generation happens.

The flow also simplifies the generation of design data representing different models of components. IP meta-data might contain a reference to an RTL-model of this IP, but also to, for example, a C-model. Using automated generation of top-level HDL wrappers, simulation scripts and HDL file lists, we can easily swap out different models of an

IP by changing a single parameter in the design meta-database, and because configuration of all models is based on the same meta-data, we reduce the risk of discrepancies between the models.

3.3 Automatic IP configuration

Re-usable IP can typically be configured for a specific application by passing parameters or macros at instantiation, HDL file pre-processing or design elaboration. To make sure that IP instances are receiving consistent parameters or macros for every step in the design flow, and thereby preventing functionality discrepancies between e.g. synthesis and simulation models, all IP parameters are kept in a central place in the IP’s meta-data. Relevant design parameters are passed on automatically to the HDL code through generated EDA tools scripts or through generated HDL code for top-level wrappers instantiating the IP.

For some IP the required degree of configurability is too high to be implemented by simply passing parameters or macros, even when using powerful System Verilog generate constructs. Examples of this would be an IP implementing a system bus interconnect, catering to a widely varying number of IP. In this case we create a dedicated HDL generator script for this IP, which can create HDL code based on configuration parameters and other meta-data in the SoC meta-database. This generator script can stay relatively simple by encapsulating in-line HDL code with scripting language constructs in for example Python or Perl. We provide a standard API to IP developers through which IP configuration parameters can be read from a design meta-database. For example, in the case of a configurable DDR memory controller IP, configuration parameters representing the number and types of required DDR memory ports can be extracted automatically from the SoC meta-database. These configuration parameters can then be accessed by the DDR memory controller IP generator script through the API, and can be used to generate the configured HDL code for this IP.

Figure 3: XML schema set

3.4 Components with System Verilog interfaces

In our proposed method, we try to make extensive use of System Verilog interfaces for its well-know advantages of code compactness and powerful functionality. An added advantage in our methodology is that in addition to a functional interface definition (i.e. interface ports and mod-ports), we also provide design constraints for each interface in the form of meta-data. This way when an IP maps a group of pins to one of the available interface definitions for the SoC platform (e.g. AHB or OCP), design constraints for these pins are automatically inherited and exported to any hier-archy level an EDA back-end tool might be run on.

One problem with System Verilog interfaces on a component is that if we want to synthesize at this component level, we lose the interface parameterization which happens when the interface is instantiated, which could be done in a different component not included for this block-level synthesis step. Also, after synthesis, the resulting netlist will have the interface ‘atomized’ to its individual ports, which means we can not directly plug it back in to the instantiating hierarchy.

We can solve these issues with extra functionality in the tool chain. Figure 4 shows a module ip_top being synthesized. In phase B, the tool chain has extracted the interface configuration from the SoC meta-database and created a temporary wrapper around the IP instantiating the parameterized interface. After synthesis, when the interfaces have all been ‘uniquified’ and atomized, this wrapper is discarded in phase C. In phase D, the tool chain has created a new wrapper instantiating the synthesized netlist and re-introducing the original System Verilog interface.

Some available synthesis tools provide this latter functionality as well, and it is possible also the problem of System Verilog interface parameterization will be solved by future generations of synthesis tools.

Figure 4: Synthesis of components with SV interfaces

3.5. Design repartitioning at meta-data level

Design repartitioning involves moving around components through different hierarchy levels in the SoC. Since in our methodology the SoC hierarchy levels and component connectivity can be specified in XML meta-data, and the HDL code for top and subsystem-level wrappers is generated, repartitioning becomes a simple function without having to parse HDL code. Our flow provides simple generator scripts for grouping and ungrouping hierarchy levels as shown in figure 5.

Figure 5: Repartitioning of the design based on meta-data

Partitioning at meta-data level is useful in various stages of the design flow. One of these is design emulation using FPGA platforms. Large SoC designs often require being repartitioned and distributed among multiple physical FPGAs. This repartitioning on HDL code is labor-intensive and bears a lot of risk of introducing discrepancies between the emulation and synthesizable models. Automated repartitioning based on a single SoC meta-database can help remedy these problems.

Another place where repartitioning is useful is in chip floor-planning. The HDL code usually reflects a functional partitioning of the design. However, often the functional partitioning does not match the required physical partitioning, e.g. when a bus adapter functionally part of an interconnect IP physically needs to move to the chip partition that contains the IP in order to meet timing requirements. The required repartitioning can be done at netlist level using off-the-shelf EDA backend tools, but when known early in the design process, can be done very easily at meta-data level as described.

3.6 Automatic IP instantiation and interconnection

With Some IP, instantiation and interconnection within the SoC are very regular tasks and can be automated based on meta-data. An example of this is I/O pads and I/O multiplexing IP. We can capture the entire I/O pad connectivity of a SoC in meta-data by specifying a number of desired physical SoC pins, a list of sources and/or drivers for this pin and a set of conditions and priorities for arbitration between them. Not only can we automatically generate configuration meta-data for an I/O multiplexer IP, we can also automatically generate the top-level HDL code instantiating and interconnecting the I/O multiplexer and I/O pads. From the same meta-data we can generate, amongst others, chip bonding diagrams and I/O related user-documentation.

The I/O connectivity meta-data is also useful in creating test-benches for chip-level verification, since we can automatically configure a verification component that serves as an I/O de-multiplexer, which prevents us from having to manually change the testbench each time the chip I/O pin multiplexing scheme changes during development.

Similar automatic instantiation and interconnecting of IP can be done for, amongst others, Design for Test (DfT) IP, clock generation IP and power management IP.

4 Deliverables

Our methodology was implemented at relatively low cost using XML and Python scripts, and consists of the following components.

• XML schemas for each design view of an SoC component
• Generator scripts implementing the functionality of generating design data from design meta-data
• Supporting scripts to extract component XML file sets from legacy design files
• XSTL transformations and XML style-sheets for meta data entry, web-publishing and documentation

We have successfully deployed our design flow for several ongoing large SoC developments and we have found that creating meta-data for existing IP requires a limited amount of resources, and expect generating design data from this will be very beneficial for productivity. Because our flow limits the minimum amount of required meta-data per IP to be usable, we are able to gradually deploy the new design flow without significantly disrupting the SoC development schedules. We also expect the amount of design errors introduced to be drastically reduced, thereby reducing required functional verification and validation efforts, resulting in a reduced SoC development time.

5 Conclusions

In this paper we introduced a platform based SoC design method that uses a centralized design meta-database containing all SoC design parameters and configurations of all IP components used. By using a meta-data centric approach, and by keeping the related tool chain for generating actual design data simple, we realized a very cost-effective way of leveraging the benefits of platform based design. We implemented our flow and found that with a limited amount of resources, we could start deploying the flow and find increased productivity very early in our SoC developments. Labor intensive tasks such as design constraint generation and design repartitioning are simplified at low cost. We also expect a reduced development and verification effort due to a reduced number of introduced design errors.

6 References

[1] Reinaldo A. Bergamaschi, William R. Lee; Designing Systems-on-chip using cores, 2000, 37th Design Automation Conference

[2] Sangiovanni-Vincentelli, A.; Carloni, L.; De Bernardinis, F.; Sgroi, M; Benefits and challenges for platform-based design, Design Automation Conference, 2004. Proceedings 41st

[3] H. Chang et al. Surviving the SOC Revolution: A Guide to Platform Based Design. Kluwer Academic Publishers, Boston/Dordrecht/London, 1999.

[4] http://www.design-reuse.com/eda; EDA tool catalog, September 2008

[5] http://www.spiritconsortium.org; The Spirit Consortium, September 2008

[6] http://www.docbook.org; DocBook XSL, November 2008