Developing a Reusable IP Platform within a System-on-Chip Design Framework targeted towards an Academic R&D Environment

By Brendan Mullane and Ciaran MacNamee,
Circuits and System Research Centre (CSRC),
University of Limerick, Limerick, Ireland

Abstract:

A key challenge facing the semiconductor industry is to combine Intellectual Property (IP) from various sources quickly and efficiently. Design times are continually pressurized by time to market requirements and increasing complexity. Industrial practices for developing System-on-Chip (SoC) IP have evolved under these pressures, but applying these practices in an academic environment presents additional challenges. The idea for developing a framework for generating IP was based on this reuse revolution and the advantages it brings to R&D. The ability to design high quality IP and to enable work practices for reuse methodology helps to achieve working SoCs in a timely and efficient manner. This paper describes a methodology for implementing IP reuse practices suited to an academic environment.

1. Introduction

Various factors are needed for efficient IP use, flexibility of integration, improved ease-of-use, minimized cost, and good work practices for developing IP. This paper is based on actual work developing an ASIC using 0.35ìm process technology. The architecture in this IC is comparable to SoC designs that use an 8-bit CPU and associated peripherals. It is shown that the framework for IP development established during this project can ensure successful deployment of both existing and new designs in future projects.

The present trend in SoC design is to make use of existing IP as much as possible. IP in the form of CPUs, DSPs and controllers, are being reused in new IC projects at semiconductor systems design houses. Engineering teams now design chips with millions of gates in less than a year. Only recently, such productivity would have been impossible, even unthinkable without hardware IP reuse. Most academic environments do not have the resources and infrastructure to enable such engineering capacity, however the underlying principles of reuse can be applied to enable more effective IP generation and knowledge retention for effective R&D.

This paper introduces a set of guidelines and a methodology used to ensure a consistent approach to designing IP and to allow for reuse of these modules in future projects. The first stage was to investigate best industrial practice. Work describing the ASIC development cycle and its impact on IP generation was carried out. A set of standards for ensuring IP quality and ease of integration was also prepared. A key objective was to ensure knowledge could be retained within the University centre to take into account expected graduate turnover.

2. IP Reuse Framework in CSRC

A review of the common issues in design use and reuse was initiated [1]. Various IP standards were reviewed and these included Freescale’s Semiconductor Reuse Standard [2], VSI Alliance’s set of standards for developing SoCs [3] and OpenMORE [4]. IP reuse could never have happened without standards or without the underlying infrastructure [5]. Design and verification reuse, a fact of life today for most SoC designs, ensures the productivity gap is kept manageable[6]. Design reuse considered a simple concept that can be easily adopted, has continued to be problematic in practice. Problems exist in getting engineers to trust that reusable IP will work every time it is used in an IC. Providing IP support services and adoption of a proper verification process develops this trust.

2.1 SoC Architecture and Infrastructure

The purpose of this project was to establish a design methodology for generating IP. The methodology involved architectural decisions and choice of design-flows for IP development accompanied by the prerequisite IC design tools. Project criteria such as the SoC architecture, third-party core use, in-house IP development and the system bus interface were all considered before the IC architecture was concluded and the peripheral integration was carried out. The basic SoC architectural diagram is shown in Figure 1 and the complete chip was taken through verification and the back-end stages of synthesis, layout, static timing analysis and final design rule checking.


Figure 1: SoC Design Architecture

The following key decisions were made in relation to the IP support structure.

2.1.1 Peripheral Bus Interface

The selection of a standard SoC system bus for connecting the CPU to the system peripherals was critical to the objectives of this project. Using a standardized bus architecture is essential to developing reusable IP. Various bus standards were investigated for the needs of the CSRC IC projects. The 8051 CPU was used in this design and although the internal Special Function Register (SFR) bus was considered, the authors wished to employ a standard bus design to be reused in other IC implementations.

Many of the major IC and IP companies base their IP portfolio development around a single SoC bus architecture. Semiconductor companies such as ARM and LSI Logic use the open source AMBATM [7] bus standard. IBM uses its own proprietary CoreConnectTM [8] bus standard. The OpenCores initiative uses the WishboneTM [9] defined bus interface. The authors observed that the AMBA bus architecture was well supported amongst the IP vendor community. This wide acceptance arises from the availability of an open bus standard that is license free and well proven in existing SoC designs. Customers have a high degree of confidence choosing IP that is considered vendor independent. Additionally, the AMBA bus is well supported by EDA companies offering verification support. The AMBA bus was chosen as the bus interface for CSRC SoC projects for these reasons.

The AMBA bus enables partitioning for modular designs[10]. Its methodology for embedded processor design encourages both a modular and first time right system design. It also accelerates product migration by supporting module reuse. In particular, the AMBA APB bus specifies a flexible interface and small overhead support for low bandwidth peripherals. The IP design using the AMBA interface is made easier by partitioning the high-end and low-end devices within the system and supports energy efficient designs. All of the peripherals in this design used the AMBA - Advanced Peripheral Bus (APB) as the standardized interface. The CPU as a single bus master was interfaced to all of the peripherals via an in-house designed AMBA bridge interface.

The advantages of using a standard bus interface for core development are well documented [1, 10, 11]. A sample AMBA APB register module, shown in Figure 2, was useful for demonstrating the desired interface design to postgraduates. The RTL code for this module helped the team to understand the principles of good coding practice to include parameterization and demonstrated the use of revision control for code changes and bug fixes. All of the IP developed in this IC project can be reused in any other AMBA based SoC applications and this aids future product and platform development

Figure 2: Sample APB module

2.1.2 3rd Party Core Licensing

Another significant task was to designate a suitable microcontroller for the project. The IP community was approached with regard to licensing of the CPU and debug cores. There were several aspects to licensing IP cores from an academic viewpoint. It was essential to ensure a licensing arrangement was made using a non-commercial research- licensing model. Many vendors were only prepared to license their cores based on a full commercial arrangement and the fees quoted were beyond an academic research budget. Some vendors were willing to consider a reduced non-commercial license fee with the re-introduction of full fees provided the IC proceeds to commercial application. Other IP vendors restricted their set of deliverables to FPGA netlist implementation only. This limited our choice of 3rd party CPU and debug cores. Fortunately, some IP companies had experience dealing with academic situations and were prepared to release IP deliverables and support for non-commercial research activity at a reduced cost. The main author was able to carry out a survey of suitable cores and came to an agreement for the 3rd party IP needed for the SoC project.

2.1.3 Design Flows

The ASIC design flow and Electronic Design Automation (EDA) tool selection is an important component of an efficient IP framework. The choice of tools must complement the design flows and aid reusability of IP. The centre accesses tool sets offered as academic programmes from the semiconductor EDA companies. The CSRC also has access to widely used EDA tools via the Europractice[12] software service scheme. Our FPGA and Digital design flows were drawn up around the availability of these tools and to plan the SoC IP development and integration. These flows were useful in determining the different stages involved in the development of IP and SoC designs. In addition to the digital design flow, a flow for FPGA prototyping was also introduced. The FPGA development allows for an inexpensive design validation platform and adds confidence by ensuring correct behavior before final tape-out.

2.1.3.1 Digital IC Design Flow

The digital design follows the classic ASIC implementation route. A number of semiconductor company websites and technical paper searches revealed the typical design flow that exists for digital ASIC design [13], [14].

Figure 3: Digital IC design Flow

The design flow and tools selection as drawn up in Figure 3 were adapted to tool availability and the choice of IC processes provided by Europractice.

2.1.3.2 FPGA Design Flow

The FPGA flow in Figure 4 is very similar to the digital IC design flow, but the design tools to implement and program a FPGA design are different. The project used the Xilinx design kits and tools made available via the Xilinx University Programme. We used Xilinx Spartan 2 and 3 boards to implement the digital design elements. The Xilinx ISE webpack is a set of tools that takes Verilog RTL code and runs it through synthesis, physical layout to device configuration. The final bit file can then be downloaded to program the FPGA device to check the functional behavior of the digital design. FPGA verification techniques and their importance in design validation and reuse are discussed later.

Figure 4: FPGA Design Flow

2.2 CAD Infrastructure

The CAD infrastructure was improved to carry out SoC development within the centre. The original structure included 3 low-grade UNIX servers for running the IC design tools and maintaining project data. A plan was initiated to upgrade the IT hardware needs. Each of the user PCs were installed with VMware Linux, allowing users to keep their Windows OS but more importantly each PC could use its own CPU processing power with Linux to deliver improved performance. Two high power Linux mainframes, acquired for maintaining the project databases were also utilized as license servers for the supported EDA tools. The new set-up provides the performance requirements to carry out IC R&D within the CSRC centre.

Another step was determining the EDA tools necessary for IP development. Tools for verification and ensuring quality of RTL code were not in place. However using our Europractice membership, the centre had access to commonly used EDA tools at a reduced cost. Tools such as ModelSim for RTL verification and Leda for RTL analysis were obtained. The latest version of Design Compiler was also upgraded in line with industry requirements.

3. Design Methodology and IP reuse Implementation

Application of reuse pays off in terms of development cost and time-to-market. This section summarizes the development milestones for a typical IP design. Defining the flow and associated design reviews helps guarantee a repeatable, high quality, and reusable block of peripheral IP. Another benefit of a documented flow is that other design groups can use this methodology to develop IP in a similar way; ensuring IP is consistent in its implementation, integration flow, deliverables, and overall quality.

3.1 Development Milestones

IP/SoC design milestones are important to the delivery of working silicon and achieving a ‘right first time’ policy. These milestones are markers placed down during the development phase to manage and measure the design activity and progress. These markers indicate reviews occurring during the critical stages of the design phase from start to end. Milestones take place at the natural progression of the project. Figure 5 and Table 1 describe the sign-off milestones to include all major design reviews.

Figure 5: IP Development Milestones

Table 1: IP Development Stages

Stage	Review	Description
FSR	Functional Spec Review	Functional specification is complete, details on effort estimation, work breakdown structure and schedule.
DSR	Design Start Review	Design start, training, RTL coding & synthesis guidelines
TPR	Test Plan Review	Complete specification of verification environment, test cases, bus-models, transactors.
RCR	RTL Code Review	RTL bug fixes identified through exhaustive verification & RTL Lint/code checking
TLR	Trial Layout Review	Establish floorplan and perform P&R. Floorplan based on module connectivity, resolve congestion and timing –look at clocking
FVR	Final Verification Review	High priority testing completed. Known bugs in the RTL are fixed. Coverage analyzed. Low priority testing ok.
FDR	Final Design Review	Review integrity checks (DRC, LVS) STA, Test Vectors and final gate-level verification with complete layout timing.

3.2 Project Database Structure

A standardized directory structure is vital for IP reusability. An efficient and easy to use database structure ensures compatibility and consistency of peripheral design. IP development involves specification, coding and verification as key design stages. As a result, many support file formats are required. IP maintenance is also a key concept in IP reuse. The ability to log and keep track of design changes is vital to the overall quality of the design. Figure 6 shows the CSRC directory structure to support the IP development stages.

Figure 6: Typical CSRC Directory Database

3.3. Reuse Guidelines

3.3.1 Specification Reviews

The design reviews are significant in terms of generating a framework for IP development and reuse. These reviews aid documentation and ensure good design practices.

3.3.2 Functional Specification

This document provides a detailed functional description of the module and is written prior to the IP development. The FSR review takes place to ensure all aspects of the peripheral functionality are covered. The specification will be used to start the design and RTL coding. The functional specification needs to be updated accordingly with any additional features requirements. The CSRC uses a draft template document as a guideline for generating functional block and IC design specifications.

3.3.3 RTL Coding and Analysis

RTL development involves coding the peripheral in a hardware description language such as Verilog or VHDL. Verilog RTL was used and a set of coding guidelines for the IP generation was issued. This set of coding principles ensures consistency, coding style quality and provides for better maintenance. The RCR is a high level review of the RTL code to ensure it is stylistically correct and maintainable. The intent is to double-check the code quality. The basis for this review is the RCR checklist. RTL analysis is carried out using Leda for crosschecking RTL code rules against the Reuse Methodology Manual (RMM). Initial FPGA/IC synthesis can also be used to highlight any RTL issues with regard to synthesis.

3.3.4 Revision Control

Revision control is integral to the concept of design reuse and ensures important information is not lost during the design phase. Revision control and file management is particularly important during RTL coding as any code lost during this stage can critically affect the overall design timeline. To help manage files, engineers use source control management systems. These are typically bundled with the Linux operating systems or available from GNU (RCS, CVS, Subversion). These code management systems provide a complete history of each file as separate versions.

3.3.5 Bug Maintenance

Dealing with bugs is an important consideration for any design framework. It is usual to find functional irregularities in the design and their occurrence does not reflect the abilities of hardware designers. Once a problem is identified, it needs to be resolved. All design teams need a method for tracking issues and ensuring their resolution. The authors proposed keeping a bug report for any design related issues.

3.4 Verification and Validation Environment

The verification phase is critical to delivering first time working silicon. Our verification methodology uses a twin track approach. Verification occurs at the module level and also at the SoC system level. The Module Verification Environment (MVE) functionally validates the core and ensures all design characteristics have been comprehensively verified. The SoC Verification Environment (SVE) tests the cores’ behavior at the system level and in particular checks the connectivity between the core interfaces. An FPGA/ASIC design verification approach was used to validate the project at the system SoC level.

3.4.1 Module Verification Environment (MVE)

An essential part of the MVE was the generation of the APB Bus Functional Model (BFM) to generate the functional behavior of the system bus. All of the peripherals were based on this standardized bus architecture and this enabled the use of a generic model to test the bus interface and registers contained within the peripherals. This model further provided an easy to use test environment. The diagram in Figure 7 illustrates this. The BFM utilized Verilog tasks for read/write accesses, including wait state control and was reused in all of the peripheral test environments. The BFM was useful for running tests to achieve confidence in the functional behavior and for targeting high code coverage.

Figure 7: APB Bus Functional Model

3.4.2 SoC Verification Environment (SVE)

The SVE consisted of a separate but similar test solution for FPGA prototyping and the ASIC system level verification. The FPGA solution was useful for mapping the complete SoC RTL code to include the CPU, debugger and all the peripherals onto a FPGA. Figure 8 illustrates the basic architecture implemented onto the FPGA device.

Figure 8: FPGA Prototype Validation

The CPU and other main peripherals are connected together as a single platform and tests were developed in R8051 CPU core program code to operate the peripheral tests. The ASIC verification environment is similar to the FPGA test bed, except in this case all tests were run using RTL and process specific gate-level stimulations. Each of the peripheral firmware tests developed for the FPGA prototyping were reused at ASIC system level.

4. Results and Conclusions

The project objective was to implement a SoC design framework for the delivery of reusable IP. The selected standard system bus aided the development of plug and play peripherals that can be reused in many other SoC applications. The development of the 8051 CPU external data bus to system bus-bridge provided for a standardized interface and simplified the peripheral development.

The design flows of Figures 4 and 5 were followed to ensure a consistent design approach for the development and equivalent support for industry standard EDA tools. The directory structure as explained in Section 3.2 was also critical for associating files with each stage of the IC development and keeping a well-managed database. Each of the implemented IP blocks follows this generic database structure and this ensures reusability going forward. Design reviews ensured confidence and quality of the IP block design. The Verilog code was reviewed to ensure revision control and RTL coding guidelines were adhered to. A similar review was carried out to ensure the verification environments at module and system level were appropriate to test the functionality of these designs. The RTL was validated on a FPGA device and tests were carried out at the system level to test the peripherals connected to the 8051 CPU.

The IP framework as discussed in this paper is suitable for implementation in an academic centre wishing to carry out a reusable IP programme. This methodology and reuse techniques are commonly used in industry, but due to funding and resource constraints, may not always be easy to set up in an academic environment. This paper discusses the implementation of IP development for lower bandwidth peripherals; nevertheless the underlying principles of IP use and reuse are the same.

4.1 Academic Centre Specifics

Staff requirements for research are ultimately resourced from graduates pursing MEng and PhD degrees. Within the CSRC, staff and academic researchers are responsible for leading projects and mentoring students. The graduates need skills development to bring them up to speed and having a structured development methodology enables deliverables to be met in a timely fashion. The advantages of IP knowledge retention was another reason for introducing the IP development framework, as work generated on projects carried out in the past would have been difficult to progress once postgraduates had completed their research degrees. This was an important issue to resolve, as useful project work carried out in the past may have been unnecessarily lost.

4.2. Future Recommendations

The cores could be further enhanced by providing a System C or C model as part of the developmental stages to further the level of abstraction and to speed up design verification and software development.

SystemVerilog is a hardware design and verification language with advanced features intended to help users develop reusable, transaction-level, coverage-driven testbenches. Techniques such as Assertion Based Verification (ABV) could be applied to the bus protocol to monitor pin activity and the application of coverage-driven tests add confidence in working silicon and provide an exhaustive testing environment. These features introduce concepts of verification reuse.

Design for Test (DfT) is often excluded from the design flow in an academic environment. DfT is a very important feature needed for IP reuse. The IEEE 1500 Standard for Embedded Core Test (SECT) specifies a core wrapper design to accommodate DfT features. This IEEE 1500 compliant wrapper design could provide a useful extension to the current IP development stages.

5. Acknowledgements

The authors acknowledge the support of the Circuits and Systems Research Centre (CSRC) within the Electronic and Computer Engineering (ECE) Dept. at the University of Limerick.

6. References

[1] Australian Microelectronics Network, "IP design and Re-use," Jun, 2005.

[2] Freescale Semiconductor, "Semiconductor Reuse Standard v3.2," Feb, 2005.

[3] VSIA Alliance, "VSIA Architecture Document v1.0," Mar, 1997.

[4] P. Bricard, Jean-Pierre Gukguen, "Applying the OpenMORE Assessment Program for IP Cores," in ISQED 2000: Synopsys, Mentor Graphics, March, 2000.

[5] J. Shandle, G. Martin, "Making embedded software reusable for SoCs," EETimes, Jan, 2002.

[6] J. Bergeron, "Writing Testbenches - Functional Verificaton of HDL Models", Kluwer Academic Publishers, 2003.

[7] ARM, "AMBA™ Specification (Rev 2.0)," ARM LTD, May 1999.

[8] IBM. CoreConnect Bus. architecture, "http://www-03.ibm.com/chips/products/coreconnect/."

[9] R. Herveille, "WISHBONE System-on-Chip (SoC) Interconnection Architecture for Portable IP Cores," OpenCores Organization, Sep, 2002.

[10] D. Flynn, "AMBA: Enabling Reusable On-Chip Designs," IEEE Micro, vol. 17, 1997.

[11] M. Kaskowitz, "Flexible, standards-based IP key," EETimes, Dec, 2002.

[12] Europractice, "http://www.msc.rl.ac.uk/europractice,"

[13] QualCore Logic, "QualCore SoC Flow."

[14] V. P. Nelson, "VLSI/FPGA Design and Test CAD Tool Flow in Mentor Graphics," Feb 15, 2006.