|
|
|
|
|
|
 |
|||
|
Philips Semiconductors Next Generation Architectural IP ReUse Developments for SoC Integration
by Geoff Mole, Marino Strik (NL), Matt Muschol
Philips Semiconductors Southampton UK, Eindhoven NL. Abstract : In the ReUse Technology Group of Philips Semiconductors an internal project known as Nx-Builder has been researching a development environment for enabling the integration of fixed and configurable System IP. The overall platform and derived product development processes of IP creation, verification and integration need to be seamlessly and consistently supported by an automated and integral tool chain, both to internal development teams and to our external customers. The use of XML-based IP electronic data books to interface to our configurable IP repository has proven both viable and intuitive. The evolution to a SPIRIT standard will greatly alleviate the costly task of integrating IP from multiple sources. Philips has successfully customized Mentor Graphics’ Platform Express to implement a specific use model for configurable IP including HW/SW co-verification using simulation tools from various vendors. Introduction Philips Semiconductors has a portfolio of SOCs, software, and system solutions for mobile and home multimedia applications known as Nexperia. While the Nexperia name has been around for a while, support in the form of tools for the Nexperia technologies has taken some time to formulate. Nexperia technologies focus on two key areas.
IP Abstraction Nx-Builder has taken the approach of building onto existing IP libraries by adding XML-based electronic datasheets to each IP. The XML databooks are based on the component schema from Mentor’s Platform Express which has formed the basis for the first release of a schema standard, known as SPIRIT (Structure for Packaging, Integrating and Re-using IP within Tool flows ). The definition and alignment of such a standard means that the integration of IP from many sources can be achieved more effectively, supported by commercial tools from several vendors. This makes IP re-useable in many architectures and for those platforms that require specific extensions or customizations, an interface to writing generators and configurators has been provided.  Figure 1 Relationship to SPIRIT Figure 1 shows the relationship between the IP libraries and the design environment (DE). On the left is a Philips internal IP repository consisting of IP views. Layered on top are additional XML metadata descriptions and special generators that are invoked to fully configure the IP based on their context in the system being built. On the right is the Nx-Builder design environment that executes the generators generating IP descriptions based on user parameters. Generator chains handle design flows that check IP compatibility, integration and top-level design view generation. The main advantage of this approach is that existing IP views in catalogue libraries only have to be appended with new XML views and any supporting generators to integrate them into the DE. Currently a number of targeted platform IP’s have Platform Express (PX) XML descriptions, in which are embedded the parameters necessary to invoke configurators and generators. IP Repositories/ Configurable IP The use model within Philips makes use of a large catalogue of configurable IP. This catalogue is known internally as the IP Yellow Pages. Generators are used to transform configuration parameters into an IP package consisting of both the XML data sheet and the configured IP views for SOC creation and verification. As a process for verifying the complete system or subsystem the configured IP packages are brought back into the DE, replacing the black box placeholders used to configure the design. This replacement operation happens at build time when all the IP blocks have been fully configured within the DE. Figure 2 Interaction with IP repository Figure 2 shows the interaction with the IP repository and the platform IP library. The configurators in the platform library read and write attribute values into the XML internal representation. The Nx-Builder DE can then extract IP views that match those configuration parameters. An interface to an IP repository called HDK (Hdli Developer’s Kit) is used as a point-tool to actually perform the configurations. The DE is subsequently updated with the configured information and the process iterates in an order defined by meta-data in the XML files. In this way engineering knowledge is effectively programmed into the XML to make sure, for example, that IP’s on a peripheral bus are fully configured before the bridge that interfaces to them. IP Integration Integrating IP into the Nx-Builder DE involves a number of discreet steps. Fixed IP is integrated as a XML view. Configurable IP is integrated as a ‘black box’ representation in XML followed by a number of steps to translate parameters into a fully configured XML view together with its verification views. The translation process involves writing a generator using an API to request a configured instance. The ‘black box’ XML contains interfaces to compatible bus structures. If new interfaces are required then new bus definitions and decoders have to be abstracted in XML. Not all steps are mandatory, this depends on on the type of IP, availability of examples and integration skills. A typical integration flow is shown in Figure 3. Figure 3 IP Integration Flow The nature of the core technology architecture makes it possible to ‘program-in’ design methodologies and features that would previously have been tackled further down the design flow chain. By providing ‘add-on’ features requested by customers it has been possible to get things right ‘up-front’ without having to apply specific workarounds or fixes required for specific toolsets manually. In order to support some of the more challenging IP blocks and to realize some of the platform architectural issues some standard transformations in XSL are being used to
The first pillar is the encapsulation of Philips IP in the PlatformExpress (PX) XML schema. Nx-Builder is used as a validation tool for both the syntax and semantics of the PX schema. In addition to this the impending release of the SPIRIT XML schema standard[2] means that the SPIRIT schema has to be layered on top to enable the recognition and processing of SPIRIT IP. Nx-Builder has been used as an environment to validate SPIRIT requirements and schema issues during the SPIRIT 1.0 development process. Figure 4 Nx-Builder Architecture The second pillar is the use of a Java API to implement a use model for both configurable IP generation and additional ‘plug-in’ functionality. An Nx-Builder API has been built on top of the PX API to help support the implementation of Philips IP generators. Specific design flows for the Nx-Builder project have been built as design level generators that use both API’s. Benefits An estimated breakdown of the perceived benefits of using Nx-Builder is shown in Figure 5. The main advantage is seen in the productivity increase, co-verification environment and design flow categories. Because Nx-Builder sets up the interfaces to both the HW and SW debugging environments and the platform libraries provide the views to exercise them, simple inconsistencies, mistakes and design problems are sorted out in less time and effort. Figure 5: Perceived Benefits Software-Based Verification The added value in the Nx-Builder DE is the reduction in top-level design time required to stitch together configurations of IP for both new and existing designs. Part of the connectivity verification strategy is to use IP level software views that share a hardware abstraction layer for communicating with control blocks like the DMA, interrupt controller, clock and reset. Each peripheral IP is delivered with a chip context independent software view that is capable of being reused in different contexts and with different control IP as long as the abstraction layer is implemented for this control IP. Software at this level plays a role in
The most important motivation for this approach is to reduce the effort when creating chip/platform derivatives and reuse across all intended users and targets. The intended users are:
The targets are:
Figure 6: IP Verification Software Architecture Nx-Builder is used to generate the chip context information used in the high-level test application for software-based verification. This configuration information, such as base address and connections to other IP blocks, is only available once an IP block has been placed on the design. Applying reuse methodologies in Platform design environments speeds up the process of getting from a high level description to a lower level set of interconnected components that can map to real technologies. Achieving some level of functional verification through HW/SW co-verification paves the way toward synthesis. Encapsulating synthesis-specific constraints and supporting filesets in the same XML views means that auto-generated netlists can be accompanied by vendor specific scripts that build the link between the abstract and the physical implementation. As the number of HDL files increases for each IP block it becomes more of an issue to provide a list of files in the order they need compiling, especially when shared sets of files are being used. The Nx-Builder DE has been able to interface to some internal tools that sort the complete fileset views into order and export them in various formats like tcl, shell script, or proprietary formats, again driven by XML templates. In this regard there are several common elements and attributes between IP views that are utilised by many EDA vendors. Specifically in the VHDL world most front-end tools require an ordered set of files and associated target libraries that can be transformed by vendor specific compilers. In this DE the filesets and target libraries are pieces of metadata described in XML that represent a view of an IP block. DFT The Design For Test flow with respect to the chip context includes generating two levels of extra hierarchy above the design, pad insertion, boundary scan insertion, and connectivity of functional, production test and GPIO signals from the design. To leverage existing solutions, Nx-Builder has re-used components and methods from the ChipBuilder project[1]. Specifically, Nx-Builder maintains the naming conventions and design structure so that the HDL and control files generated can be used in-house. Figure 7 shows the extra levels of hierarchy that are automatically inserted into the design for ‘production test builds’. Figure 7: DFT Hierarchy In addition subsystem DFT is currently being investigated. It will re-use generators from the chip level flow, but rather than add the levels of hierarchy, it will prepare the subsystem for inclusion in the chip. In this case, we are unable to automatically calculate the width of the test rail from the number of available chip level pins, so the designer has to enter this manually. The DFT flow will combine the following elements in the Nx-Builder flow – 1. Philips specific test structures will be automatically connected, using existing methodologies. 2. Scan chains can be connected by invoking a 3rd party test compiler 3. Philips scan tools can also be invoked to generate test patterns. 4. Simulations can then be invoked to check the test is correctly inserted and connected. Synthesis The synthesis flow makes use of constraint files delivered with the IP views aligned as much as possible with the current CoReUse internal standard for database structure. Generators have been written to produce preparatory scripts and makefiles. This flow extracts synthesis specific meta-data from XML files together with key database and top-level netlist generation files as part of the normal build chain. The current infrastructure supports extra hooks to add these features to the choices of available flows. We are also hoping to make the natural synthesis step towards FPGA prototyping. Nx-Builder lends itself well to the concept of producing a system or subsystem view for a target implementation. ESL Modelling In combination with existing processor models we are looking at Nx-Builder as a future tool for design space exploration. By switching in different models, such as design signoff and System C transactors we can raise the abstraction level. Figure 8 shows a simplistic model of the intended build process for a mixed System C and HDL environment. Part of the build process activity is to create the makefiles and directory structures to support the traditional Software Development Environment (SDE). Figure 8: System C build process By replacing certain IP models with bus transactors, R/W memory operations triggered by software can be done on the host processor. This approach is still under development and several alternatives are being investigated. Conceptually we are looking at:-
Using the Nx-Builder approach real System design flows can be constructed that automate the integration and verification of IP at the system and sub-system level. Experience today suggests that further work will promote good practice, reproducible designs and encourage consistent configurations based on the encapsulation of real platform engineering knowledge. The ability to utilize an API to both extract design information and customize design flows and tools makes both IP reuse and tool reuse an attractive proposition for SoC integration. This open architecture based on a partition of IP metadata from IP tooling has been used in the development of today’s sub-systems. These sub-systems will form the building blocks of more complex systems that interface to both high level modelling and traditional RTL based approaches. References [1] ChipBuilder User Manual, Marko Edzes, Theo Didden, John Wagensveld, CCP, 15-06-2002 Verification software description [2] SPIRIT User Guide V1.0 alpha, DAC 2004 www.spiritconsortium.org [3] Peryer, Mark “Spirit compliant Platform Design using an IP Repository”, IP Soc Conf, November 2003 |
|
|
|
|
|
|
|
Home | Feedback | Register | Site Map |
|
|
|
All material on this site Copyright © 2017 Design And Reuse S.A. All rights reserved. |